
\documentclass[runningheads,a4paper]{article}

\usepackage{amssymb}
%\setcounter{tocdepth}{3}
\usepackage{graphicx}
\linespread{2}
\usepackage{url}
\urldef{\mailsa}\path|{jharri1}@gmu.edu|
\newcommand{\keywords}[1]{\par\addvspace\baselineskip
\noindent\keywordname\enspace\ignorespaces#1}

%\usepackage[caption=false]{subfig}
\usepackage{wrapfig}
%\usepackage{multicol}
\usepackage{amsmath}
\usepackage{color}
\usepackage{xcolor}
\usepackage{listings}
\usepackage{subfigure}


\usepackage{caption}
\DeclareCaptionFont{white}{\color{white}}
\DeclareCaptionFormat{listing}{\colorbox{gray}{\parbox{\textwidth}{#1#2#3}}}
\captionsetup[lstlisting]{format=listing,labelfont=white,textfont=white}

\lstset{
	language=Java,
	basicstyle=\small\sffamily,
	tabsize=4,
	numbers=left
}

\renewcommand{\topfraction}{0.85}
\renewcommand{\textfraction}{0.1}
\renewcommand{\floatpagefraction}{0.75}

\providecommand{\abs}[1]{\lvert#1\rvert}

\newcommand{\doctitle}[0]{Retirement Redux: A replication of Axtell's and Epstein's Retirement Age model}

\begin{document}
\title{\doctitle}
%\shorttitle{Retirement Redux}
\author{Ernesto Carrella \\ Joseph F. Harrison}
%\authorrunning{E. Carrella and J. F. Harrison}
%\titlerunning{Retirement Redux}
%\institute{George Mason University}

%\toctitle{\doctitle}
%\tocauthor{Authors' Instructions}
\maketitle

\section*{Abstract}
In this paper, we present a replication of Axtell's and Epstein's Retirement Age model\cite{axtell_coordination_2006}. 
The original model is straightforward in design and nicely generates patterns of norm adoption. 
We hoped that due to its simplicity, we'd be able to replicate the model perfectly but this was not the case.
The parameters affect the model in ways that are consistent with the original, but our transition and convergence times
are much shorter, sometimes by as much as two orders of magnitude.

\section{Introduction}
\label{sec:intro}

The ability to reproduce experimental results is a critical part of the scientific endeavor \cite{popper1959logic}. 
In the natural sciences, one may find that a particular experiment was tainted by faulty equipment, a contaminated sample, or unsound analysis. 
Similarly, the behavior of computational models may be affected by idiosyncracies of the programming language or tools used, programming errors, or other flaws in methodology. Replicating computational models is a powerful form of independent verification \cite{wilensky2007making,rand2006verification}.

We replicated Axtell's and Epstein's Retirement Age model\cite{axtell_coordination_2006}. 
We chose this model because of its straightforward design and because of the ancillary benefit of having a more portable version of this model.
By keeping the model simple, we hoped to achieve a perfect replication. The replication was only a partial success.
We managed to replicate parameters relationship and their general effect on retirement decisions, but we couldn't reproduce identical numeric results.
Our model always seemed to transition and converge faster than the original.

We decided to use the MASON simulation toolkit \cite{luke2005mason} to create our replication. 
The original model was programmed in C and is specific to Mac OS version 9. 
MASON is written in Java, which allows broad portability between different operating systems.
The trade-off of using Java and using a platform like MASON is a decrease in flexibility.
This project was too simple to take advantage of most of the perks of MASON.
Unfortunately it wasn't simple enough to ignore some of the additional complications of Java, especially garbage collection.

\subsection{Model Description}

The model simulates retirement decisions of heterogeneous agents.
Agents differ one from the other in terms of their behavior rules, social network and death age.
Every year each agent decides whether to retire or keep working. 

There are three types of agents.
Random agents choose whether to retire or not by tossing a coin.
Rational agents always retire as soon as possible.
Imitators look at the agents in their social network who are eligible for retirement, and follow what the majority of them are doing.

The main feature of the model is the gradual emergence of retirement norms.
Although 65 is fixed to be the retirement age, the population decides to retire at that age only gradually.
This paper tries to model retirement decision without economic rationale.
Mimesis is all that matter.

\subsection{Parameters}

We implemented all the parameters of the original model as shown in Figure~\ref{fig:params}. 
Note that the proportion of imitators is specified implicitly as the remaining group not specified as either rational or random.
The item labeled ``ProportionRetired'' is for monitoring the output, rather than setting a parameter.

\begin{figure}
\centering
  \subfigure[Table from Original Paper]{
   \includegraphics[width=0.46\textwidth] {figs/orig-param-table.png}
 }
 \subfigure[Model tab in MASON replication]{
   \includegraphics[width=0.46\textwidth] {figs/ModelParametersTab.png}
 }
\caption{Parameters in the original model and in the replication.}
\label{fig:params}
\end{figure}

\section{Replication}

\subsection{MASON}
We decided to replicate the model trough the MASON framework \cite{luke2005mason}.
This allows for the use of premade structures when programming in Java.
We did not have, nor we should have had, access to the original code in C.
Replication would be invalidated if we used anything but the original paper.

This allowed for the highlighting of both some advantages and disadvantages of Java and MASON.
These should be weighted by the added difficulty of not using NETLOGO or other ABM-specific languages.
One should also keep in mind that the original paper was also object oriented.

The greatest advantage of using Java is the ability to use premade structures.
We used an \textit{ArrayList} to store Agent's networks.
This allows us to remove deceased friends and to modify the size of the network over time.
For this very simple model, everything else would have been an overkill.

Another great advantage of Java is the proliferation of other packages we can integrate to our model.
OpenCSV was used to output formatted data.
Network packages like JUNG would have had very little added value.
Again, the simplicity of the model didn't call for any addition.

One feature of MASON is the complete separation between the graphic and the model code.
We decided to put this to a test so that each team-mate would focus on only one side of the code.
This proved not very successful.
The model-side had to be progressively modified so that it would update the graphics-side at critical times.
This is particularly troublesome given the fact that in this model the graphical side is ancillary.

\subsection{Object Orientation}

Intuitively, agents in this model share many similarities.
They age, they die, they are either allowed or not to retire.
They are heterogeneous both in their endowments and their behavior.

Code-wise their different endowments are their variables, their different behavior are their class structure.
We can take advantage of Java's OO paradigm.
The UML diagram in figure~\ref{UML} describes the approach taken.
Most of the behavior is recycled from the \textit{Agent} abstract class.
Each subclass then overrides only the code pertaining retirement decision.

\begin{figure}
 \begin{center}
  \includegraphics[scale=.45]{figs/UML.png}
\caption{The class structure of the agents}
\label{UML}
 \end{center}
\end{figure}

We decided to make the super-class Agent as abstract rather than interface so that we could write common behavior together.
Classes in MASON are agents when they implement the \textit{Steppable} interface.
The Agent's step method is described in code~\ref{step}.
This allows for sub-classes to override the \textit{doIRetire} function and still use aging and death of the super-class.
{
\linespread{1}
\begin{lstlisting}[float,caption= {Agent's step class}, label={step}]
public void step(SimState arg0) {
	age++;
	if(age >= deathAge){
		this.die();
	}
	else if (status == Status.WORKING && age >= model.retirementAge)	
		status = doIRetire();	
}

\end{lstlisting}
}

\subsection{Garbage Collection}

An important feature of Java is automatic garbage collection.
The programmer doesn't manually affect memory allocation. 
His responsibility is to remove any reference to the object he wants to delete.

Garbage collection proved quite a headache in our project.
All references to agents are stored in a single matrix.
We had hoped that removing these agents from the matrix would be enough to clean the memory.
It was not so.

Two components made garbage collection a major problem during development.
The first was the MASON scheduler itself.
To run an agent in MASON one needs to schedule it.
Under the hood this means holding a reference of the agent in one \textit{heap} object, preventing garbage collection.
Scheduling comes into two types: scheduling once or scheduling forever.
Because our agents had to act every year, we scheduled them forever but that made their reference permanent in the heap.

This forced us into a ``least-worst'' analysis of our design choices.
We could schedule agents once every turn by checking if they were still alive.
This would have been burdensome as we would have had to create a new steppable just to make the check every turn.
Similarly we could have made the matrix holding agents steppable and let it activate agents directly.
But with this we would have lost many advantages of the premade \textit{Schedule} class, in particular automatic shuffling of activation order.
The third way was to try and remove agents in the scheduler manually.

Stopping an agent scheduled forever proved more troublesome than it should be.
The \textit{Schedule} class does not allow for direct removal. 
The \textit{Steppable} interface, common to all agents, does not allow for stopping.
An unrelated \textit{Stoppable} is returned when the agent is first scheduled.
What we had to do was to manually store the reference to the stoppable and pass it to the agent after it has been scheduled.
Only then the agent dies can finally stop itself.

The other garbage collection issue was with social networks.
Agents every year purge their networks of their deceased friends. 
But when they ``die'' the remaining references in the \textit{ArrayList} are automatically not removed.
This meant that some of the old social networks referenced each other even when all its agents were dead.
This prevented them from being garbage-collected.


\subsection{Visualization}

The original model by Axtell and Epstein contained a unique custom graphical user interface (GUI) that we set out to match as closely as possible (see Figure~\ref{fig:gui-comparison}).
This required us to overcome some obstacles due to the conventions of MASON visualization. 
For instance, MASON stores grid objects in a 2D array where the first index corresponds to the $x$ coordinate of the object and the second index corresponds to the $y$ coordinate. 
Specifically, ObjectGrid2D defines the array as \lstinline!public Object[/**x*/][/**y*/] field;! 
This presents a challenge when we want to access a cohort in a single array since \lstinline!field[i]! gives the $i^{th}$ column of cells. In the original model, cohorts are arranged as rows. 
We solved this problem by storing the agents in an auxiliary array \lstinline!Agent[][] agentMatrix! such that \lstinline!agentMatrix[i]! gives the $i^{th}$ cohort.
To get the auxiliary array into the form MASON needs for displaying, we copied and transposed to the aforementioned \lstinline!field!.

\begin{figure}
\centering
  \subfigure[Original Paper]{
   \includegraphics[width=0.9\textwidth] {figs/orig-gui-screenshot.png}
 }
 \subfigure[MASON replication]{
   \includegraphics[width=0.9\textwidth] {figs/gui-screenshot1.png}
 }
\caption{Comparison of the original visualization with the visualization in the replication MASON model. }
\label{fig:gui-comparison}
\end{figure}


\section{Results}
Replication was only a partial success. 
In most cases we achieved relational equivalence \cite{springerlink:10.1007/BF01299065} rather than numerical identity.
In a few situations docking simply failed.

The behavior of standard cases was replicated successfully.
Figure~\ref{figure4} and figure~\ref{figure5} show side by side the retiring behavior of the system and our replication.
Every parameter was set as in the original paper.

\begin{figure}
\centering
  \subfigure[Original Paper]{
   \includegraphics[scale =.40] {figs/figure4.png}
 }
 \subfigure[MASON replication]{
   \includegraphics[scale =.13] {figs/figure4_replication.png}
 }

\caption{20\% rational agents case comparison}
\label{figure4}
\end{figure}

\begin{figure}
\centering
  \subfigure[Original Paper]{
   \includegraphics[scale =.40] {figs/figure5.png}
 }
 \subfigure[MASON replication]{
   \includegraphics[scale =.13] {figs/figure5_replication.png}
 }

\caption{5\% rational agents case comparison}
\label{figure5}
\end{figure}

We manage to replicate the fact that the less rational agents, the more it takes for society to retire.
We also managed to replicate the loss of monotonicity as rational agents decrease in numbers.
We couldn't replicate numerically the waiting period, unfortunately.
Figure~\ref{figure5}'s replication takes a fourth of the time it took the original model to let mass-retirement emerge.



\subsection{Parameter Sweep}

Parameter sweep replication was less successful than the previous chapter.
Figure~\ref{figure6} shows the difference in replicating runs by switching the proportion of agents in the population.
On one side the results are decent enough: the more the population is dominated by imitators the more it takes to retire en masse.
On the other the numbers are very different.

\begin{figure}
\centering
  \subfigure[Original Paper]{
   \includegraphics[scale =.70] {figs/figure6.png}
 }
 \subfigure[MASON replication]{
   \includegraphics[scale =.45] {figs/figure6_replication.pdf}
 }

\caption{Rational agents sweep, black: 0\% random, red: 5\% random, blue 10\% random}
\label{figure6}
\end{figure}

We got better results when replicating changes in the maximum network size.
As figure~\ref{figure8} shows we replicate both the increase in average and standard deviation.
Again, we failed to achieve numerical identity.
Our model can be 10 times faster in reaching full-retirement state.

\begin{figure}
\centering
  \subfigure[Original Paper]{
   \includegraphics[scale =.90] {figs/figure8.png}
 }
 \subfigure[MASON replication]{
   \includegraphics[scale =.35] {figs/figure8_replication.pdf}
 }

\caption{Changes in time to get full-retirement equilibrium by changing maximum network size. Grey dots represent runs}
\label{figure8}
\end{figure}

\subsection{Transition from 65 to 62}

\begin{figure}
 \begin{center}
  \includegraphics[scale=.60]{figs/figure1.png}
\caption{Male retirement rate by age, 1960, 1970, and 1995-1996. Reproduced from \cite{axtell_coordination_2006}.}
\label{fig:real-data}
 \end{center}
\end{figure}

The original paper presented a chart showing real world retirement statistics and how they changed between 1960 and 1995-1996 (see Figure~\ref{fig:real-data}). 
Although U.S. law was changed in 1961 to allow men to retire at 62 instead of 65, the norm did not change immediately. 
By 1970, a new norm of 62 had begun growing but there were not a significant increase of people retiring at 64 or 63. 
That is, the mode did not slide gradually from 65 to 62; it was replaced by a new mode.

The original paper was not able to produce this mode replacement dynamic, though later work using small-world and lattice networks was more successful \cite{axtell2001effects}. We were also not able to reproduce this dynamic using the original model specification and we did not extend it using different network structures.

Our replication, like the original model, results in a gradual slide of the norm from 65 to 62. 
However, our transition times were generally longer than those in the original. 
The original showed that the transition time is longer with a higher proportion of imitators and our replication showed the same effect.

There were some important differences though.
In our model, transition dynamics are markedly non-linear.
Specifically, either the transition occurs almost instantly or it never happens.
In fact, when the transition fails a new equilibrium with almost everyone working emerges.

Very interestingly is that we can get somewhat more similar results to the paper if we focus on transition from 65 to 60 instead.
In this case the transition is quick but not instantaneous and depends on the population proportions.

It is instructive as it stretches the definition of relational equivalence.
In this case, at first sight, it looks like an utter failure.
But with a slight modification of the target we can get more reasonable fits.

\subsection{Threshold dynamic}

We find that whether imitator agents follow their threshold strictly or not is very important.
When exactly half of the eligibles friends have retired, should the agent retire as well?
To show the effects we fix the number of rational agents to 10\% and we run the same simulation fixing the seed.
Figure~\ref{laxstrict} show the result of the simulation.

\begin{figure}
 \begin{center}
  \includegraphics[scale=.30]{figs/laxstrict.png}
\caption{The black line is the simulation with strict threshold, the red line is without}
\label{laxstrict}
 \end{center}
\end{figure}

This highlights one of the oft-neglected advantages of replication.
Whenever the original source code is missing, only through replication one is able to make additional tests of someone else's model.

This goes also to show that minor assumptions might have great impact.
In this case a change in threshold from $.5$ to $.499$ mean the difference between mass retirement and perennial work.

\section{Conclusion}

In this paper, we attempted to replicate the look and dynamics of the Axtell's and Epstein's retirement model.
We were partially successful in reproducing the dynamics although our transition times were much shorter.
This incongruity deserves more exploration in the future. 

This exercise also gave us increased perspective on the advantages and disadvantages of using Java in general and MASON in particular.
Java's object-oriented structure helped in the creation of different agent types that avoided redundant code.
MASON allowed us to visualize and test the model as we progressed, which was very helpful.

We discovered some of the pitfalls of Java's garbage collection, which while important, took time that could have been better spent exploring model dynamics.


\bibliographystyle{splncs03}
{
\linespread{1}
\bibliography{references}
}

\end{document}
